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(54) Latency-reducing bandwidth-prioritization for network servers and clients 



(57) Communications bandwidth available to net- 
work servers and computers running client processes is 
allocated among connections available to those devices 
based on sets of priorities. Those priorities include type 
ci information being retrieved, how fast user connec- 
tions can receive information, which part of a document 
is being transmitted, user identity, stored indicia indicat- 



ing importance of the document and the state of appli- 
cation processes running on said computer. Bandwidth 
is reallocated on an event driven basis upon arrival of a 
new request for retrieval, finishing sending information 
in response to a retrieval request, cancellation of a re- 
trieval request, detection of the inability of a user con- 
nection to use all of the bandwidth allocated to it, a 
change of priority and timeout of a timer. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention 5 

The invention relates to communication systems 
and more particularly to client server communication 
systems in which communications resources provided 
to a retrieval request or to a connection to a particular 
server can be adjusted to reflect priorities. 

Description of Related Art 

Accessing the content of servers on a network, such 
as the World Wide Web (WWW), is often agonizingly 
slow. Response time may be so stow that users cancel 
their request for a page and select another page, per- 
haps that of a competitor. Getting enough text to the user 
quickly so that he may begin reading is important to pre- 
vent him from canceling his request. Reducing the initial 
latency from request to delivery of readable text will re- 
sult in a more satisfying browsing experience for the us- 
er. 

Data compression is known. Various data compres- 
sion algorithms may be employed depending upon the 
type of data (text, image, video, audio) to be transmitted. 
Fortunately, many if not most network servers employ 
compression. Unfortunately, the latency problems asso- 
ciated with retrieving server pages continue to grow 
worse with increasing network usage. 

SUMMARY OF THE INVENTION 

The present system provides apparatus, systems, 
methods and computer program products which will al- 
low improved average response time in client server 
technology. This is accomplished by prioritizing the con- 
tent of network pages and allocating server or client 
bandwidth accordingly The prioritization scheme is driv- 
en by the need to render a viewable page as quickly as 
possible so that the user may begin reading it. In the 
prior art, all files that make up the final appearance of a 
WWW page (text, style sheets, graphics, audio etc.) are 
sent with equal priority. By using a prioritization scheme, 
it is possible to dramatically reduce the latency per- 
ceived by the user which, in turn, increases the per- 
ceived usability of the web site. 

Two mechanisms facilitate this. First, the order in 
which information is displayed to the user "hides" some 
of the latency thus creating the perception of faster re- 
sponse time. Second, by monitoring individual connec- 
tions it is possible to determine which connections are 
not currently utilizing the bandwidth initially made avail- 
able to them. When this occurs, the unused bandwidth 
is allocated to all other existing connections which might 
be able to use it. 

The same concepts can be applied to the client-side 



(the user) in one form by allowing the client to indicate 
to the server the speed with which the client will accept 
information. In another form, a client that has multiple 
browsers connected to respective multiple network 
servers can prioritize each connection to insure, for ex- 
ample, that the current browser window's connection is 
allocated more bandwidth than a minimized browser 
window's connection. This is not possible using the prior 
art since all connections are given the same priority. 

The invention is directed to computer apparatus, 
such as that found at a server, for allocating communi- 
cations bandwidth to a plurality of user connections. The 
apparatus includes a processor configured to allocate 
communications bandwidth to said user connections 
based on at least one set of priorities. 

The invention is also directed to computer appara- 
tus, such as that running a client process, for allocating 
communications bandwidth to a plurality of server con- 
nections based on at least one set of priorities. 

The invention is also directed to a communications 
system operating on a network and having at least one 
server and at least one computer running a client proc- 
ess in which said at least one server or said at least one 
computer allocates bandwidth to a plurality of network 
connections based on at least one set of priorities. 

The invention is also directed to methods for oper- 
ating servers and clients to allocate bandwidth to con- 
nections based on at least one set of priorities. 

The invention also relates to computer program 
products useful for carrying out the methods and for im- 
plementing the apparatus described. 

The foregoing and other features, aspects and ad- 
vantages of the present invention will become more ap- 
parent from the following detailed description of the 
present invention when taken in conjunction with the ac- 
companying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The object, features and advantages of the system 
of the present invention will be apparent from the follow- 
ing descriptions, in which: 

Figure 1 A illustrates a computer of a type suitable 
for carrying out the invention as either a client or a serv- 
er. 

Figure 1B illustrates a block diagram of the com- 
puter of Figure 1 A. 

Figure 1C illustrates an exemplary memory medi- 
um containing on or more programs usable with the 
computer of Figure 1 A. 

Figure 2A is an illustration of one exemplary form 
of implementing the invention using a network such as 
an intranet. 

Figure 2B is an illustration of another exemplary 
form of implementing the invention using a typical inter- 
net arrangement. 

Figure 3 is an illustration of bandwidth allocation 
from a network server to several clients. 
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Figure 4 is a database schema organized as an ex- 
emplary way for storing file-type priorities. 

Figure 5 is a database schema of an exemplary 
way for storing current connection information, namely 
in an Allocated Utilization Table (AUT). 

Figure 6 is a flowchart of a process to initiate dy- 
namic bandwidth allocation by the server. 

Figure 7 A is a flowchart of a process for dynamic 
bandwidth allocation by the server. 

Figure 7B is a illustration depicting the result of one 
iteration of the dynamic bandwidth allocation procedure 
of Figure 7A 

Figure 8A is a database schema organized as an 
exemplary way for storing client browser-status priori- 
ties. 

Figure 8B is a flowchart of a process for client-side 
control of bandwidth allocation. 

Figure 9 is a flowchart of a process for changing 
the priority of a connection after a fixed amount of data 
has been transmitted. 

Figure 1 0A is a database schema organized as an 
exemplary way for storing a value representing the re- 
spective amount of data specific files need to have 
transmitted at high priority. 

Figure 1 0B is a flowchart of a process for changing 
the priority of a connection after the variable amount of 
data indicated in Figure 10A has been transmitted. 

Figure 11 A is a database schema organized as an 
exemplary way for storing a list of customer passwords 
and the corresponding priority multiplier. 

Figure 11 B is a flowchart of a process for increasing 
the priority of a connection using the information con- 
tained within Figure 11 A. 

Figure 12A is a database schema organized as an 
exemplary way for storing a list of documents and their 
associated priority multipliers. 

Figure 12B is a flowchart of a process for increas- 
ing the priority of a connection using the information con- 
tained within Figure 12A. 

NOTATIONS AND NOMENCLATURE 

The detailed descriptions which follow may be pre- 
sented in terms of program procedures executed on a 
computer or network of computers. These procedural 
descriptions and representations are the means used 
by those skilled in the art to most effectively convey the 
substance of their work to others skilled in the art. 

A procedure is here, and generally conceived to be 
a self-consistent sequence of steps leading to a desired 
result. These steps are those requiring physical manip- 
ulations of physical quantities. Usually, though not nec- 
essarily, these quantities take the form of electrical or 
magnetic signals capable of being stored, transferred, 
combined, compared; and otherwise manipulated. It 
proves convenient at times, principally for reasons of 
common usage ; to refer to these signals as bits, values, 
elements, symbols, characters, terms, numbers, or the 



like. It should be noted, however, that all of these and 
similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels ap- 
plied to these quantities. 

Further, the manipulations performed are often re- 
ferred to in terms, such as adding or comparing, which 
are commonly associated with mental operations per- 
formed by a human operator. No such capability of a 
human operator is necessary, or desirable in most cas- 
es, in any of the operations described herein which form 
part of the present invention; the operations are ma- 
chine operations. Useful machines for performing the 
operation of the present invention include general pur- 
pose digital computers or similar devices. 

The present invention also relates to apparatus for 
performing these operations. This apparatus may be 
specially constructed for the required purpose or it may 
comprise a general purpose computer as selectively ac- 
tivated or reconfigured by a computer program stored 
in the computer. The procedures presented herein are 
not inherently related to a particular computer or other 
apparatus. Various general purpose machines may be 
used with programs written in accordance with the 
teachings herein, or it may prove more convenient to 
construct more specialized apparatus to perform the re- 
quired method steps. The required structure for a variety 
of these machines will appear from the description giv- 
en. 

DESCRIPTION OF THE FREFERRED 
EMBODIMENTS 

Figure 1 A illustrates a computer of a type suitable 
for carrying out the invention. Viewed externally in Fig- 
ure 1 A, a computer system has a central processing unit 
100 having disk drives 11 OA and 11 OB. Disk drive indi- 
cations 1 1 0A and 1 1 0B are merely symbolic of a number 
of disk drives which might be accommodated by the 
computer system. Typically, these would include a flop- 
py disk drive such as 1 1 0A, a hard disk drive (not shown 
externally) and a CD ROM drive indicated by slot 11 OB. 
The number and type of drives varies, typically, with dif- 
ferent computer configurations. The computer has a dis- 
play 120 upon which information is displayed. A key- 
board 130 and a mouse 140 are typically also available 
as input devices. Preferably, the computer illustrated in 
Figure 1 A is a SPARC workstation from Sun Microsys- 
tems, Inc. 

Figure 1 B illustrates a block diagram of the internal 
hardware of the computer of Figure 1A A bus 150 
serves as the main information highway interconnecting 
the other components of the computer. CPU 155 is the 
central processing unit of the system, performing calcu- 
lations and logic operations required to execute pro- 
grams. Read only memory (160) and random access 
memory (165) constitute the main memory of the com- 
puter. Disk controller 170 interfaces one or more disk 
drives to the system bus 150. These disk drives may be 
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floppy disk drives : such as 1 73, internal or external hard 
drives, such as 172, or CD ROM or DVD (Digital Video 
Disks) drives such as 171 . A display interface 175 inter- 
faces a display 120 and permits information from the bus 
to be viewed on the display. Communications with ex- s 
ternal devices such as a network can occur over com- 
munications port 185. 

Figure 1C illustrates an exemplary memory medi- 
um which can be used with drives such as 1 73 in Figure 
1 B or 1 1 0A in Figure 1 A. Typically, memory media such 
as a floppy disk, CD ROM, or Digital Video Disk will con- 
tain the program information for controlling the computer 
to enable the computer to performs its functions in ac- 
cordance with the invention. 

Figure 2A is an illustration of one exemplary form 
of implementing the invention using a network such as 
an intranet. The network 200 is typically an internal or- 
ganizational network that connects the client computing 
device and at least one WWW server. 

Figure 2B is an illustration of another exemplary 
form of implementing the invention using a typical Inter- 
net arrangement. The client computing device 250 con- 
nects via one network with the client's Internet Service 
Provider (ISP) 240. The ISP 240 then connects via the 
Internet 230 to a WWW server 260 requested by the us- 
er. 

Figure 3 is an illustration of bandwidth allocation 
from a network server to several clients. The network 
server 300 has a predetermined amount of bandwidth 
N 310 which it must divide 320, 330, 340 and 350 be- 
tween multiple clients 360, 370, 380, and 390. Note that 
the bandwidth allocation each client receives varies. 
This variance reflects the bandwidth allocation of the pri- 
oritized client connections as described in Figures 4-7, 
hereinafter. 

Figure 4 is a database schema organized as an ex- 
emplary way for storing file-type priorities. The table has 
two columns: File Type 400 and Priority 410. An HTML 
file 420 will have a priority of 4 (430). A style sheet 440 
will have a priority of 3 (450). Priority 2 470 is reserved 
for future use. GIF 480 and JPG files 490 both have pri- 
orities of 1 (485 and 495). 

Figure 5 is a database schema organized as an ex- 
emplary way for storing connection information about 
clients actively involved in retrievals. The Allocation Uti- 
lization Table (AUT) 500 shown is a data structure used 
to track the status of each active current connection. For 
each such active current connection the file name 510, 
priority 520 (determined from Figure 4), allocated band- 
width 530, utilized bandwidth 540, and a recalculation 
Boolean variable 550 are stored in the AUT. The AUT is 
used to provide the data for the bandwidth re-allocation 
algorithm of Figure 7. In rows 560 and 565 it should be 
noted that the allocated bandwidth exceeds the utilized 
bandwidth. When this difference exceeds a threshold, 
the recalculation variables are automatically set to 
FALSE to prevent re-allocation of more bandwidth than 
the connection can utilize. 



Figure 6 is a flowchart of a monitoring procedure to 
initiate dynamic bandwidth allocation by the server. A 
continuous monitoring loop 600 responds to events af- 
fecting bandwidth allocation. One event is a new request 
(605) for bandwidth. Normally, this will occur when an 
HTTP GET command is received by the server. Follow- 
ing a new request 605 the requested file name and its 
associated priority based on its file-type are placed into 
the AUT and the recalculation variable is set to TRUE 
(610). Then the recalculation of bandwidth allocation al- 
gorithm is invoked (650) which updates the AUT, then 
the AUT is used to provide parameters to the bandwidth 
allocator (655) and the monitoring loop resumes 600. 

An event indicating the completion or cancellation 
of a transmission connection (615) will remove the con- 
nection from the AUT (620). Then the recalculation of 
bandwidth allocation algorithm is invoked (650) which 
updates the AUT, the AUT is then used to provide pa- 
rameters to the bandwidth allocator (655) and the mon- 
itoring loop resumes (600). 

An event indicating that the client is not utilizing all 
of the allocated bandwidth occurs when the average 
throughput of data (calculated, for example, using the 
number of ACKs received per unit of time) falls below 
the allocated bandwidth maximum data rate (625). Var- 
ious protocols from in the prior art, including Stop-And- 
Wait Link Utilization and Sliding- Window Flow Control, 
can be used to calculate the actual data rate. For exam- 
ple, one might add the packet lengths of a number of 
packets sent over a period of time and divide the total 
by the length of the period of time to determine effective 
throughput, or actual data rate. That value is then stored 
in the AUT and the recalculation variable is set to FALSE 
so that for the remainder of that retrieval request the 
bandwidth re-allocation algorithm will not increase that 
connection's bandwidth (630). Then the recalculation of 
bandwidth allocation algorithm is invoked (650) which 
updates the AUT, the AUT is then used to provide pa- 
rameters to the bandwidth allocator (655) and the mon- 
itoring loop resumes (600). 

An event indicating a change in the relative priority 
of a transmission (640) may occur. The priority for that 
transmission is then updated in the AUT (660). Then the 
recalculation of bandwidth allocation algorithm is in- 
voked (650) which updates the AUT, the AUT is then 
used to provide parameters to the bandwidth allocator 
(655) and the monitoring loop resumes (600). 

A scheduled event may be set to occur periodically 
(645). This event is to handle any situation not handled 
by the other events. Then the recalculation of bandwidth 
allocation algorithm is invoked (650) which updates the 
AUT, the AUT is used to provide parameters to the band- 
width allocator (655) and the monitoring loop resumes 
(600). 

Figure 7A is a flowchart of a procedure for dynamic 
bandwidth allocation by the server. The procedure be- 
gins by initializing several variables: MaxBW is set to 
the maximum bandwidth available to the server, 
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COUNT is set to the number of rows in the AUT (i.e., 
the number of current connections), SumOfPriorities is 
set to zero, and index I (a loop counter) is set to one 
(700). If index I is not greater than COUNT (705) then 
there are more rows to process in the AUT. At 710 the 
MaxBW is decreased by any difference between the al- 
located bandwidth and the utilized bandwidth. If the AUT 
recalculation variable for the current row is TRUE then 
the priority of the current row is added to the SumOfP- 
riorities (720). This action prevents those connections 
that are being under-utilized from receiving more band- 
width which they have already demonstrated they can- 
not use. Then index I is incremented by one (725) and 
the loop continues at 705 until all the rows in the AUT 
have been processed. 

Index I is re-initialized at 730 to one and another 
loop commences at 735. While index I does not exceed 
COUNT (735), the recalculation variable of each row is 
checked 760. If it is FALSE then the current AUT row 
has its allocated bandwidth set to equal its utilized band- 
width (755) thus reflecting the true state of the system. 
If it is TRUE, then the current AUT row allocated band- 
width variabJe is assigned the value of the ratio of the 
current row's priority to the SumOfPriorities and the uti- 
lized value is set to equal the allocated value (765). This 
assumes that the client connection can utilize the new 
bandwidth it has been allocated. If it cannot, then it will 
be detected and corrected via Figure 6 at 625. In either 
case, index I is incremented (770) and processing the 
remaining rows in the AUT continues at 735. If all the 
rows have been processed (735) then the AUT has been 
completely updated and is ready for use by the band- 
width allocator in Figure 6 at 655 and the process is 
terminated (750). 

Figure 7B is a illustration depicting the result of one 
iteration of the dynamic bandwidth allocation procedure 
of Figure 7A. Assume a web server is transmitting an 
HTLM document and a JPG file to one client and a GIF 
file to another client. Using the bandwidth allocation al- 
gorithm described in Figure 7A and using the priority 
scheme of Figure 4, the sum of the priorities is 6 so the 
HTLM document will receive 4/6 (66.7%) of the band- 
width, and both the JPG file and GIF file will receive 1/6 
(16.7%) of the bandwidth. Now assume that the second 
client can only utilize 10% of the total bandwidth (which 
was determined using the process in Figure 6 at 625). 
The initial state 780 is shown in rows 781 , 782 and 783. 
Note that 783 has unused bandwidth capacity of 6.7% 
of the server's total bandwidth. In order for this band- 
width to be used, the bandwidth re-allocation algorithm 
of Figure 7A is run again. 

The results of the reallocation are shown in the final 
state 790. Since the recalculation variable of the AUT 
row for the JPG file would have been set to FALSE, the 
sum of the priorities is now 5 and the proportional dis- 
tribution of the spare bandwidth would be 4/5 for the 
HTML document 791 and 1/5 for the GIF document 792. 
So, 4/5 of the 6.7% available bandwidth is re-allocated 



to the HTML document, resulting in a final bandwidth 
utilization of 72.0%. Repeating the process for the GIF 
documents lead to a final bandwidth utilization of 1 8.0%. 
The JPG file retains the 10.0% share it could use prior 

s to the re-allocation. 

Figure 8 A is a database schema organized as an 
exemplary way for storing client browser-status priori- 
ties. Each browser has an ID 800, a Status 810 and a 
Priority 815. The row 820 has an ID of A, a status of 

io "Has Focus" (i.e., is the user's active browser) and a 
high priority of 4. Browser ID B 821 does not have the 
focus but is visible on the screen and has a priority of 2. 
Browser ID C 823 does not have the focus and is not 
visible (perhaps minimized) and has a low priority of 1. 

is Figure 8B is a flowchart of a procedure for client- 
side control of bandwidth allocation. Similar to the algo- 
rithm of Figure 7A, this procedure utilizes the ratio of a 
process priority to that of the sum of the priorities of all 
active process. The MaxBW constant is initialized at 830 

20 with the maximum bandwidth the client has available to 
manage. The priorities of the browsers in use are 
summed (840) and that sum is then used as the divisor 
of the individual browser priorities to determine the 
bandwidth to be allocated to each browser (850). Next, 

25 the bandwidth is allocated, e.g. by controlling the 
number of packets acknowledged to the server to obtain 
the desired throughput rate (860) (as described in Fig- 
ure 6 at 625) and the process terminates (870). 

Figure 9 is a flowchart of a procedure for changing 

30 the priority of a connection after a fixed amount of data 
has been transmitted. As an alternative or a supplement 
to the preferred embodiment, an HTML file could be as- 
signed a high priority only during the transmission of the 
first N KB. This approach might be used when only the 

35 first screen or part of the first screen of text must be de- 
livered as rapidly as possible. The process begins by 
initializing N to the number of KB to transmit at high pri- 
ority (900). Then the New Request event (910) (Figure 
6 at 605) is triggered. The number of KB transmitted is 

40 monitored (920) and when the number transmitted 
equals N (930) the AUT is updated to reflect a lower pri- 
ority by triggering the Change Priority event (950) (Fig- 
ure 6 at 640). 

Figure 1 0A is a database schema organized as an 

45 exemplary way for storing a value representing the var- 
iable amount of data a specific file needs have transmit- 
ted at high priority. As another alternative or supplement 
to the preferred embodiment, an HTML file could be ex- 
amined (e.g., using a browser) to determine the number 

50 of bytes necessary to render the first page. This number 
of bytes would then be stored (1 005) in a database along 
with the HTML file name 1000. The database rows 1006, 
1007 and 1008 are examples of the name and byte tu- 
ples required. 

55 Figure 1 0B is a flowchart of a procedure for chang- 
ing the priority of a connection after the variable amount 
of data indicated in Figure 10A has been transmitted. 
The variable N is set, via a database lookup of the file 
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name, to the number of bytes that need to be transmitted 
with high priority 1010. The New Request event is trig- 
gered (1 020) (Figure 6 at 605) and the number of bytes 
transmitted is monitored (1030). When the number of 
bytes transmitted equals N (1040) the Change Priority s 
event is triggered (1060) (Figure 6 at 640) which then 
updates the AUT table and begins the bandwidth re-al- 
location process and this process is terminated (1070). 

Figure 11 A is a database schema organized as an 
exemplary way for storing a list of customer passwords 10 
and a corresponding priority multiplier. As another sup- 
plement or alternative to the preferred embodiment, the 
priority given to web pages could be based on informa- 
tion about the person requesting them. For example, 
valued customers can be given higher priority. When im- '5 
plemented in a log- in type website, a list of passwords 
that have higher than normal priority could be kept in the 
form of the tuple Customer Password 1100 and Priority 
Multiplier 1105. As rows 1106, 1107 and 1108 show, the 
multiplier can be different based on how valued the cus- 20 
tomer is. In another approach, a list of network address- 
es of valued customers is maintained and checked 
against the address of client's connections to the server 
to determine priorities. 

Figure 11 B is a flowchart of a procedure for increas- 2s 
ing the priority of a connection using the information con- 
tained within Figure 11 A. A customer accesses a web- 
site and enters his password (1110). If the password is . 
in the priority database of Figure 11A (1120) then the 
priority for the document requested is set to the standard 30 
priority for that type of document multiplied by the priority 
multiplier 1130. For example, if an HTLM document has 
a priority of 4 and the multiplier is 2 the new priority would 
be 8. Then the New Request event is triggered (1140) 
(Figure 6 at 605) and this process is terminated (1140). 35 

Figure 12A is a database scheme organized as an 
exemplary way for storing a list of documents and their 
associated priority multipliers. As another supplement 
or alternative to the preferred embodiment, the priority 
given to web pages could be based on content of the *o 
pages themselves and their value to the web page own- 
er. Providing an order form on the user's screen may be 
deemed to have a higher priority than delivering product 
information. The tuples of HTLM page name 1200 and 
Priority Multiplier 1205 can be stored in the database. 45 
As rows 1206, 1207 and 1208 show, the multiplier can 
be different based on how important a particular HTML 
document is. 

Figure 12B is a flowchart of a procedure for in- 
creasing the priority of a connection using the informa- so 
tion contained within Figure 12A. The user requests an 
HTML page (1210). If the page name is found in the pri- 
ority database (1220) then the transmission priority be- 
comes the normal transmission priority multiplied by the 
priority multiplier (1230). Then the New Request event 55 
is triggered (1240) (Figure 6 at 605) and this process is 
terminated (1250). 

There has thus been described a communication 



system in which communication resource allocated by 
either servers or clients can be adapted based on prior- 
ity of various types. As a result, user satisfaction with 
the network is enhanced by obtaining desired informa- 
tion in a prompt fashion and server and client resources 
are prioritized to enhance throughput of the network. 

Although the present invention has been described 
and illustrated in detail, it is clearly understood that the 
same is by way of illustration and example only and is 
not to be taken by way of limitation, the spirit and scope 
of the present invention being limited only by the terms 
of the appended claims. 



Claims 

1 . Computer apparatus for allocating communications 
bandwidth to a plurality of user connections, com- 
prising: 

a. a bus; 

b. at least one communications interface con- 
nected to said bus; 

c. a processor connected to said bus, said proc- 
essor configured to allocate communications 
bandwidth to said user connections serviced by 
said at least one communications interface 
based on at least one set of priorities. 

2. The apparatus of claim 1 , in which one set of prior- 
ities comprises priorities based on type of informa- 
tion being retrieved. 

3. The apparatus of claim 2 in which said type of infor- 
mation includes at least one of information in HTML . 
format, information in a style sheet format, informa- 
tion in a GIF image format and information in a 
JPEG image format. 

4. The apparatus of claim 1 , in which one set of prior- 
ities comprises priorities based on how fast user 
connections can receive information. 

5. The apparatus of claim 1 , in which one set of prior- 
ities comprises priorities based on which part of a 
document is being transmitted. 

6. The apparatus of claim 1 , in which one set of prior- 
ities comprises priorities based on user identity. 

7. The apparatus of claim 1 , in which one set of prior- 
ities comprises priorities based on stored indicia in- 
dicating importance of the document. 

8. Computer apparatus for allocating communications 
bandwidth to a plurality of server connections, com- 
prising: 
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a. a bus; 

b. at least one communications interface con- 
nected to said bus; 

c. a processor connected to said bus, said proc- 
essor configured to allocate communications 
bandwidth to server connections serviced by 
said at least one communications interface 
based on at least one set of priorities. 

9. The apparatus of claim 8, in which one set of prior- 
ities comprises priorities based on the state of ap- 
plication processes running on said processor. 

10. The apparatus of claim 9, in which the state of ap- 
plication processes comprises the foreground or 
background state of a process. 

11. The apparatus of claim 9, in which the state of ap- 
plication processes comprises the degree to which 
a window in which a process is running is ready for 
use by a user. 

12. A method of operating a server on a network, com- 
prising the step of: 

a. providing an element for allocating commu- 
nications bandwidth at a server to a plurality of 
user connections based on at least one set of 
priorities. 

1 3. The method of claim 1 2 in which said set of priorities 
includes at least one of: type of information being 
retrieved, how fast user connections can receive in- 
formation, which part of a document is being trans- 
mitted, user identity and stored indicia indicating im- 
portance of the document. 

14. The method of claim 12 in which bandwidth is allo- 
cated to a user connection based on the ratio of pri- 
ority that user connection bears to the sum of prior- 
ities of all user connections. 

15. The method of claim 13 in which bandwidth alloca- 
tion is recalculated on an event driven basis. 

16. The method of claim 14 in which events triggering 
recalculation include at least one of: arrival of a new 
request for retrieval, finishing sending information 
in response to a retrieval request, cancellation of a 
retrieval request, detection of the inability of a user 
connection to use all of the bandwidth allocated to 
it, a change of priority and timeout of a timer. 

17. A method of controlling communications by a proc- 
ess on a computer connected to a network, com- 
prising the step of: 

a. providing an element for allocating commu- 



nications bandwidth to a plurality of server con- 
nections in use by said process based on at 
least one set of priorities. 

5 18. The method of claim 17 in which said priorities are 
based on the state of application processes running 
on said processor. 

19. A communications system, comprising: 

10 

a. a network; 

b. at least one server connected to said net- 
work; and 

c. at least one computer running at least one 
is process connected to said network, 

in which said at least one server or said at 
least one computer allocates bandwidth to a plural- 
ity of network connections based on at least one set 
20 of priorities. 

20. The system of claim 1 9 in which said set of priorities 
includes at least one of: type of information being 
retrieved, how fast user connections can receive in- 

25 formation, which part of a document is being trans- 
mitted, user identity, stored indicia indicating impor- 
tance of the document and the state of application 
processes running on said computer. 



30 21. A computer program product, comprising: 

a. a memory medium; 

b. a computer program, stored on said memory 
medium, said computer program comprising in- 

35 structions for allocating communications band- 

width at a server to a plurality of user connec- 
tions based on at least one set of priorities. 

22. A computer program product, comprising: 

40 

a. a memory medium; 

b. a computer program, stored on said memory 
medium, said computer program comprising in- 
structions for allocating communications band- 

45 width to communications connections based on 

at least one set of priorities. 
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